---title: "Transcrição da Prova Teórica 1 — nome: " disciplina: "Gestão de Projetos de Software" codigo_disciplina: "GPS" avaliacao: "Prova Teórica 1" periodo: "2026-2" data: "2026-10-19" discente: nome: "Ronald Rodrigues Vitorino" matricula: "20243003723" curso: "Engenharia de Computação" turma: "Unidade Timóteo" nota_total: 23.4 nota_maxima: 25.0 legibilidade_percentual: 92 metadados_transcricao: transcritor: "Antigravity Assistant (Visão Computacional)" data_transcricao: "2026-10-19" grau_fidelidade: "Fiel (ipsis litteris), preservando rasuras e pontuação original" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Ronald Rodrigues Vitorino ## Questão 1 ### 1.1 (1,5) Projeto vs. operação — três características com evidências: O Professor Agente é um projeto, visto que tem início, meio e fim; com o fim do trabalho, não há uma manutenção contínua e todo o processo é estruturado de forma a gerar um entregável mínimo que seja eficaz. ### 1.2 (2,0) Duas alternativas de trade-off sem sacrificar qualidade + impacto no Triângulo de Ferro: Os tradeoffs mais relevantes seriam em escopo, sacrificando algumas funcionalidades para focar nas mais essenciais, e em custo, optando por um modelo de IA mais barato para reduzir o custo por chamada. ### 1.3 (1,5) Ciclo de vida e justificativa (preditiva, ágil ou híbrida): O ciclo de vida é ágil, visto que o projeto possui uma curta duração e é muito propenso a mudanças e riscos externos; a abordagem ágil é a mais efetiva em permitir a entrega a curto prazo e lidar com as possíveis mudanças ou problemas que surjam no caminho. --- ## Questão 2 ### 2.1 (1,5) EAP de dois níveis (substantivos, regra dos 100%, $\ge 3$ pacotes de trabalho): ``` [Espaço para desenho/diagrama da EAP] /--- chat c/ usuário / Interface +--- dashboard do professor Professor /---- Integração com interface Agente -+--- LLM -+----- Sanitização de entrada \---- Armazenamento de conversas \ Banco de dados ``` A EAP garante que 100% do entregável de um nível correspondem aos entregáveis dos níveis abaixo. Todo entregável é decomposto em pacotes de trabalho, e estes representam a totalidade do entregável acima. ### 2.2 (1,5) Issue completa (título, descrição, critério, estimativa/estratégia) e 2ª Issue com justificativa relativa: Título: Implementação do armazenamento de conversas Descrição: Implementar um armazenamento de conversas, de forma que cada chamada do bot seja armazenada no banco de dados por usuário. Estimativa: 8h ISSUE 2: Título: Sanitização de entrada Estimativa: 4h Como a 2ª issue possui uma complexidade menor, a sua estimativa de tempo também é menor em relação à Issue 1. ### 2.3 (2,0) Milestones vs. Sprints + contexto para Kanban sem Sprints: Por via de regra, milestones dependem diretamente das sprints, visto que o fechamento de uma sprint gera um milestone. Não é possível usar milestones para substituir sprints, pois elas norteiam o andamento do projeto e garantem prazo para a entrega ser feita de forma ágil e em tempo hábil. No caso de bugs ou funcionalidades fora do escopo que são desejáveis, é possível criar uma issue para elas no Kanban, sem uma sprint atrelada. --- ## Questão 3 ### 3.1 (1,5) DoD, relação com pipeline CI/CD e omissão de testes de segurança: O definition of done correspondem a parâmetros mínimos que garantem que a entrega feita está completa e funcional; nesse caso, a pipeline de CI/CD é um dos critérios da DoD, e não é possível afirmar que a funcionalidade está pronta com a omissão dos testes, pois a funcionalidade pode vir com bugs, além de não passar em todos os critérios da DoD (o que, por definição, faz com que a funcionalidade não esteja pronta). ### 3.2 (1,5) CoQ — classificar (a), (b), (c), (d) + custo mais alto: a: custo de prevenção; b: custo de avaliação; c: custo de falha externa; d: custo de falha interna. O custo de falha externa tende a ser o mais alto, pois ocorre com o projeto em produção, e qualquer downtime ou erro pode significar uma pior percepção do usuário, maiores dificuldades em mitigar o problema e até mesmo menos receita, em casos que o lucro é visado. ### 3.3 (2,0) Heurística 1:10:100, limites em IA e uso como argumento qualitativo: A regra 1:10:100 diz que custa $1 para corrigir o problema no levantamento de requisitos, $10 na fase de testes e $100 em produção. No caso de projetos com IA, o risco de erros em fase de produção é alto devido às alucinações ou ataques de prompt injection. Como não é possível prever seu comportamento, algumas barreiras e testes de segurança são cruciais para entender a taxa de compreensão e alucinação da LLM, mantendo-a sempre acima dos valores preestabelecidos no início do projeto. --- ## Questão 4 ### 4.1 (1,5) Risco vs. problema (Cap. 6) + quadrante na matriz $P \times I$ e estratégia de resposta: ``` Prob. ^ | Médio Crítico | * Vazamento da chave de API | | Baixo Médio +-------------------------> Impacto ``` Era um risco que se tornou um problema com o vazamento. Nesse caso, a estratégia de resposta mais eficaz é a mitigação, já que o problema já ocorreu. ### 4.2 (1,5) Três ações imediatas + uma ação preventiva (defesa em profundidade): Revogação (ou rotação) da chave de API, investigação da causa do problema e remoção da chave do histórico do gitlab. Como ação preventiva, a revisão das configurações e a criação de um pipeline de CI/CD que busca por chaves de API, além de um gitignore como medida extra. ### 4.3 (2,0) Risco de entrada modelado (causa, P, I, mitigação, contingência) + mitigação de saída + artefato de documentação: Risco: prompt injection; causa: um aluno deseja a resposta de um exercício imediatamente e engana a IA p/ dar a resposta, ou alterar o banco de dados; probabilidade: alta; impacto: alto. Mitigação: sanitização de entrada e permissão read-only para a IA no banco de dados. Formalização através de uma ADR, pois é o mais adequado para justificar uma decisão arquitetural e é comunicável de forma assíncrona com os demais envolvidos no projeto. --- ## Questão 5 ### 5.1 (1,5) Comunicação síncrona vs. assíncrona no GitLab + prática/ritual de registro de decisões: A comunicação síncrona tende a resolver problemas mais rapidamente, pois todos estão presentes e focados em uma mesma pauta. Entretanto, há os problemas de conseguir um horário em que todos possam participar, e essa comunicação é mais propensa a ruídos. A comunicação assíncrona não depende de um horário comum para todos, sendo útil para problemas menos críticos e menos propensa a ruído, mas pode demorar mais tempo para resolver um problema em relação à comunicação síncrona. Para um ritual de registro de decisão crítica, é possível realizar uma rápida reunião, e a formalização da decisão em uma ADR. ### 5.2 (1,5) Matriz Poder $\times$ Interesse dos 5 stakeholders, premissas e estratégia de comunicação: ``` Poder ^ | Manter satisfeito Gerenciar de perto | 3 2, 5 | | Monitorar Manter informado | 4 1 +---------------------------------------------> Interesse Legenda: 1. Alunos 2. Professor 3. Equipe de desenvolvimento 4. Provedor da API 5. Coordenação do curso ``` Professor: é cliente e patrocinador do projeto; Coordenação de curso: aprova o uso da ferramenta nas turmas. Para a coordenação, é interessante uma conversa formal presencial ou através de uma chamada, semanalmente, para falar sobre o andamento do projeto e possíveis caminhos para a sua continuação. ### 5.3 (2,0) Conflito pedagógico vs. técnico — Thomas-Kilmann (1 escolha justificada + 2 inadequadas): Para resolver esse conflito, o ideal seria conceder, mas de forma a encontrar um meio-termo, como: uma resposta curta, seguida de uma explicação e uma pergunta socrática. Nesse caso, adiar a decisão não seria ideal, por tratar-se de algo urgente e que não pode ser adiado para obter mais informações.